Shutting down a plurality of software components in an ordered sequence

ABSTRACT

An apparatus in one example comprises a manager component in communication with a distributed software application. The distributed software application comprises a plurality of software components that run within one or more executables. The manager component shuts down the plurality of software components in an ordered sequence based on one or more dependency relationships among the plurality of software components.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application contains subject matter that is related to the subjectmatter of the following applications, which are assigned to the sameassignee as this application. The below-listed applications are herebyincorporated herein by reference in their entireties.

-   -   “INSTRUCTING MANAGEMENT SUPPORT SOFTWARE OF A FIRST SOFTWARE        COMPONENT TO SET UP A COMMUNICATION CHANNEL BETWEEN THE FIRST        SOFTWARE COMPONENT AND A SECOND SOFTWARE COMPONENT,” by Buskens,        et al., co-filed herewith;    -   “SELECTING A PROCESSOR TO RUN AN EXECUTABLE OF A DISTRIBUTED        SOFTWARE APPLICATION UPON STARTUP OF THE DISTRIBUTED SOFTWARE        APPLICATION,” by Buskens, et al., co-filed herewith;    -   “SOFTWARE COMPONENT INITIALIZATION IN AN ORDERED SEQUENCE,” by        Buskens, et al., co-filed herewith;    -   “DISTRIBUTED SOFTWARE APPLICATION SOFTWARE COMPONENT RECOVERY IN        AN ORDERED SEQUENCE,” by Buskens, et al., co-filed herewith;    -   “MANAGER COMPONENT FOR CHECKPOINT PROCEDURES,” by Buskens, et        al., co-filed herewith;    -   “MANAGER COMPONENT THAT CAUSES FIRST SOFTWARE COMPONENT TO        OBTAIN INFORMATION FROM SECOND SOFTWARE COMPONENT,” by Buskens,        et al., co-filed herewith;    -   “FIRST AND SECOND MANAGER COMPONENTS THAT COMMUNICATE TO        INITIALIZE AND/OR SHUT DOWN SOFTWARE COMPONENTS IN AN ORDERED        SEQUENCE,” by Buskens, et al., co-filed herewith;    -   “MANAGER COMPONENT RESOURCE ADDITION AND/OR RESOURCE REMOVAL ON        BEHALF OF DISTRIBUTED SOFTWARE APPLICATION,” by Gong, et al.,        co-filed herewith;    -   “SUBSTITUTE MANAGER COMPONENT THAT OBTAINS STATE INFORMATION OF        ONE OR MORE SOFTWARE COMPONENTS UPON FAILURE OF A FIRST MANAGER        COMPONENT,” by Buskens, et al., co-filed herewith.

TECHNICAL FIELD

The invention relates generally to distributed software applications andmore particularly to management of distributed software applications.

BACKGROUND

In known distributed software applications, software components aredistributed among a plurality of executables (i.e., software capsules orsoftware entities). Each of the executables contains one or moresoftware components that perform some portion of the functionality ofthe distributed software application. The executables of the distributedsoftware application may all run on a single processor or may be dividedup and run across a plurality of processors.

During operation of the distributed software application, stateinformation is created, system resources are allocated, and/or databasesare updated. If the software components of a distributed softwareapplication shut down without a preplanned shutdown sequence, then thedistributed software application may leave system resources in aninconsistent state. As one shortcoming, without a proper shutdownsequence, the distributed software application may not properly storethe state information, release the allocated system resources, and/orupdate the databases.

During shutdown of a distributed software application divided into aplurality of executables running on a single processor, the distributedsoftware application may shut down the executables by following apreplanned shutdown sequence for the executables. As one shortcoming,executing the shutdown sequence at the executable level may not serve tofully leave the system resources in a consistent state. The distributedsoftware application may run on a single processor or the executables ofthe distributed software application may be divided across a pluralityof processors. As another shortcoming, the shutdown sequence is unableto fully coordinate a shutdown of the executables and softwarecomponents of the distributed software application divided across aplurality of processors.

Thus, a need exists to shut down a distributed software application in amanner that stores state information, releases system resources, and/orleaves the system resources in a consistent state.

SUMMARY

A manager component for a distributed software application employsdependency relationships between software components of the distributedsoftware application during shutdown of the distributed softwareapplication. The manager component shuts down the software components inan ordered sequence based on the dependency relationships among thesoftware components. When software components have dependencies on othersoftware components, the manager component shuts down the softwarecomponents in a proper sequence to store state information, releasesystem resources, and/or leave one or more database of the distributedsoftware application in a consistent state.

In one embodiment, there is provided an apparatus comprising a managercomponent in communication with a distributed software application. Thedistributed software application comprises a plurality of softwarecomponents that run within one or more executables. The managercomponent shuts down the plurality of software components in an orderedsequence based on one or more dependency relationships among theplurality of software components.

In another embodiment, there is provided an apparatus comprising amanager component that shuts down a first software component, of adistributed software application, that runs on a first processor and asecond software component, of the distributed software application, thatruns on a second processor in an ordered sequence based on one or moredependency relationships between the first and second softwarecomponents.

In yet another embodiment, there is provided a method for: obtaining oneor more dependency relationships among a plurality of softwarecomponents that run within one or more executables of a distributedsoftware application; establishing an ordered sequence for shutdown ofthe plurality of software components based on one or more of the one ormore dependency relationships; and shutting down the plurality ofsoftware components in the ordered sequence.

DESCRIPTION OF THE DRAWINGS

Features of exemplary implementations of the invention will becomeapparent from the description, the claims, and the accompanying drawingsin which:

FIG. 1 is a representation of an exemplary implementation of anapparatus that comprises a distributed software application and amanagement infrastructure.

FIG. 2 is a representation of exemplary logic that serves to allow amanager component of the management infrastructure to employ an orderedsequence to shut down the distributed software application of theapparatus of FIG. 1.

DETAILED DESCRIPTION

Turning to FIG. 1, an apparatus 100 in one example comprises adistributed software application 102 and a management infrastructure103. The management infrastructure 103 performs one or more managementoperations on the distributed software application 102. The managementinfrastructure 103 comprises a manager component 104. For example, themanager component 104 may coordinate one or more of starting, stopping,initializing, shutting down, and monitoring the distributed softwareapplication 102, detecting failures of the distributed softwareapplication 102, recovering the distributed software application 102,propagating state changes about distributed software application 102,and the like.

The distributed software application 102 represents a softwareapplication divided among a plurality of executables (i.e., softwarecapsules or software entities). For example, the distributed softwareapplication 102 comprises a plurality of executables 106, 107 and 108.The distributed software application 102 may run on a single centralprocessing unit (“CPU”) or may be divided between multiple CPUs. Forexample, the executables 106 and 107 may run on processor 110 and theexecutable 108 may run on processor 112. The processor 110 comprises anexecutable manager 114 and the processor 112 comprises an executablemanager 116. The executable managers 114 and 116 in one example are partof the management infrastructure 103.

The executable managers 114 and 116 start, stop and monitor executablesof the distributed software application 102 that run on the processors110 and 112, such as the executables 106, 107 and 108. To start or stopthe executable 106, the executable manager 114 invokes operating systemcommands to start or stop the executable 106. The executable managers114 and 116 monitor communication channels and/or diagnostics on behalfof the executables 106, 107 and 108. Should one or more of theexecutables 106, 107 and 108 fail, the respective one of the executablemanagers 114 and 116 informs the manager component 104.

To detect failures of the executables 106, 107 and 108 the executablemanagers 114 and 116 register with an operating system to receivenotifications when the executables 106, 107 and 108 terminate eitherabnormally or as a result of explicit commands sent to the executables106, 107 and 108. To detect failures of software components 124, 126,127 and 128 within the executables 106, 107 and 108, the executablemanagers 114 and 116 send status queries to the software components 124,126, 127 and 128 and expect to receive status responses from thesoftware components 124, 126, 127 and 128.

Each of the executable managers 114 and 116 comprise a communicationinterface 118 for communication with the manager component 104. Theexecutable managers 114 and 116 receive instruction from the managercomponent 104. For example, the executable managers 114 and 116 mayreceive instructions at the communication interface 118 from the managercomponent 104. The executable manager 114 is encapsulated in anexecutable 120 running on the processor 110 and the executable manager116 is encapsulated in an executable 122 running on the processor 112.

The executables 106, 107 and 108 comprise one or more softwarecomponents 124, 126, 127 and 128. For example, the executable 106encapsulates the software components 124 and 126, the executable 107encapsulates the software component 127, and the executable 108encapsulates the software component 128. Within each of the executables106, 107 and 108 may be tens, hundreds, or even thousands of othersoftware components (e.g., analogous to the software components 124,126, 127 and 128).

The software components 124, 126, 127 and 128 represent softwaresub-entities of the executables 106, 107 and 108. For example, thesoftware components 124, 126, 127 and 128 represent logical blocks ofsoftware of the executables 106, 107 and 108. The software components124 and 126 in one example are developed independently and then puttogether within the executable 106. The software components 124, 126,127 and 128 each perform some portion of the overall functionality ofthe distributed software application 102. The software components 124,126, 127 and 128 work together to make the distributed softwareapplication 102 achieve the desired operation. The distributed softwareapplication 102 may provide any functionality for a computer system. Thedistributed software application 102 in one example comprises a callprocessing software application. For example, the distributed softwareapplication 102 sets up and/or tears down telecommunication sessions ina telecommunication network.

In one embodiment, each of the software components 124, 126, 127 and 128comprise application software 130, management support software 132, amanagement support software communication interface 134, and one or moreapplication software communication interfaces 135. The softwarecomponents 124, 126, 127 and 128 employ the management support softwarecommunication interfaces 134 to receive communications from the managercomponent 104. The software components 124, 126, 127 and 128 employ theapplication software communication interfaces 135 to receivecommunications from other software components of the software components124, 126, 127 and 128. An application programming interface (“API”) 136communicatively couples the application software 130 with the managementsupport software 132 in each of the software components 124, 126, 127and 128. The application software 130 and the management supportsoftware 132 can exchange information through the applicationprogramming interface 136.

The application software 130 is the portion of the software components124, 126, 127 and 128 that performs some portion of the overallfunctionality of the distributed software application 102. Themanagement support software 132 is the portion of the softwarecomponents 124, 126 and 128 that cooperates with the manager component104 to perform management operations on the software components 124, 126and 128. The application software 130 is part of the distributedsoftware application 102 and the management support software 132 is partof the management infrastructure 103.

An application developer creates the application software 130 of thesoftware components 124, 126, 127 and 128 to achieve the designatedfunctionality of the software components 124, 126, 127 and 128. Forexample, the application developer creates the application software 130of the software components 124, 126, 127 and 128 to achieve the overallfunctionality of the distributed software application 102.

To alleviate the application developers from being required to writesoftware into each of the software components 124, 126, 127 and 128 tointerface with the manager component 104, a code generator in oneexample automatically generates the management support software 132. Tocreate the management support software 132, a configuration file 150 inone example is input into the code generator. The configuration file 150comprises connection information and/or architecture information of thedistributed software application 102. The code generator creates codefor the management support software 132. The code for the managementsupport software 132 is compiled and linked with the applicationsoftware 130 in the software components 124, 126, 127 and 128. Themanagement support software 132 may be different for each of thesoftware components 124, 126, 127 and 128, as will be appreciated bythose skilled in the art.

The manager component 104 comprises a communication interface 138 forreceiving incoming communications. The communication interface 138 isemployable for receiving the configuration file 150. The managercomponent 104 may employ other means to receive the configuration file150, such as reading the configuration file 150 directly from a disk orfile system. The communication interface 138 may also receivecommunications from the executable managers 114 and 116, as well ascommunications from the software components 124, 126, 127 and 128.

The manager component 104 may also use the communication interface 138for receipt of external system information from an external environment151. In one example, the external environment 151 represents othercomponents of the system that are in communication with the managercomponent 104. In another example, the external environment 151represents another management infrastructure in communication with themanagement infrastructure 103.

The manager component 104 is encapsulated with zero or more othersoftware components in an executable 140. The executable 140 thatcontains the manager component 104 may be run on either of theprocessors 110 and 112. The manager component 104 in one example isactive and the apparatus 100 may have one or more standby managercomponents (e.g., analogous to the manager component 104). If themanager component 104 fails, then one of the standby manager componentsbecomes active and gains managerial control of the distributed softwareapplication 102.

One advantage to the manager component 104 controlling shutdown of thedistributed software application 102 is that the manager component 104alleviates application developers from being required to write softwareinto each of the software components 124, 126, 127 and 128 to coordinateshutdown. The manager component 104 controls shutdown of the softwarecomponents 124, 126, 127 and 128 on behalf of the software components124, 126, 127 and 128. For example, the manager component 104 interfaceswith the management support software 132 coupled with the applicationsoftware 130 in the software components 124, 126, 127 and 128 tosequence shutdown of the software components 124, 126, 127 and 128.Therefore, the manager component 104 saves the application developerseffort of creating software to sequence shutdown.

The management infrastructure 103 provides shutdown managementfunctionality as a reusable asset for distributed software applications.The management infrastructure 103 in one example comprises a portion ofa high availability (“HA”) infrastructure. The manager component 104 inone example comprises a high availability manager component operating ina high availability infrastructure. The high availability infrastructurecontrols management operations on the software components 124, 126, 127and 128 for the distributed software application 102. For example, thehigh availability infrastructure controls shutdown of the softwarecomponents 124, 126, 127 and 128 in the ordered sequence for thedistributed software application 102, along with terminating theexecutables that encapsulate the software components 124, 126, 127 and128. The high availability infrastructure is usable to controlmanagement operations for the distributed software application 102 oranother distributed software application. The high availabilityinfrastructure is able to continue processing while switching betweenactive and standby components in the high availability infrastructure.

To startup of the distributed software application 102, the managercomponent 104 initializes each of the software components 124, 126, 127and 128 and each of the executables 106, 107 and 108. The managercomponent 104 in one example imports the configuration file 150 toobtain connection information of the distributed software application102. The configuration file 150 provides information to the managercomponent 104 to allow the manager component 104 to control thedistributed software application 102. The configuration file 150 iscreated to store connection information and/or architecture informationof the distributed software application 102. The configuration file 150in one example provides the manager component 104 with information aboutthe set of executables 106, 107 and 108, the number of each type of theexecutables 106, 107 and 108, the mapping of the software components124, 126, 127 and 128 to the executables 106, 107 and 108, the types ofthe software components 124, 126, 127 and 128, and the number of eachtype of the software components 124, 126, 127 and 128 in each of theexecutables 106, 107 and 108.

The configuration file 150 in one example indicates one or moredependency relationships among the software components 124, 126, 127 and128. The manager component 104 employs a list of the dependencyrelationships to establish an ordered sequence for startup. The managercomponent 104 initializes the software components 124, 126, 127 and 128in the ordered sequence for startup based on the dependencyrelationships among the software components 124, 126, 127 and 128. Forexample, if the software component 124 is dependent on the softwarecomponent 126, then the manager component 104 initializes the softwarecomponent 126 before initializing the software component 124 as part ofthe ordered sequence. If the software components 124 and 126 are freefrom any dependency relationships, then the manager component 104 mayinitialize the software components 124 and 126 in parallel as part ofthe ordered sequence.

Once all of the executables 106, 107 and 108 and the software components124, 126, 127 and 128 are initialized during startup, the distributedsoftware application 102 may run and perform an intended function.During operation of the distributed software application 102, stateinformation is created, resources are allocated, and/or databases areupdated. At shutdown of the distributed software application 102, it isdesirable to save the state information, release the allocatedresources, and confirm that the databases are in a consistent state. Totransition the distributed software application 102 from activeoperation to a non-operational state, the manager component 104 shutsdown the distributed software application 102 in an ordered sequencebased on the dependency relationships among the software components 124,126, 127 and 128. The manager component 104 may shut down thedistributed software application 102 in the ordered sequence at thelevel of the software components 124, 126, 127, and 128, then mayshutdown the executables 106, 107 and 108. The manager component 104 maycoordinate the shutdown of the executables 106, 107 and 108 and/or thesoftware components 124, 126, 127 and 128 running on a single processoror divided among a plurality of processors, such as the processors 110and 112.

Turning to FIGS. 1-2, an illustrative description of one exemplaryoperation of the apparatus 100 is now presented, for explanatorypurposes. The manager component 104 comprises a high availabilitymanager component operating in a high availability infrastructure. Tobegin operation of the apparatus 100, the distributed softwareapplication 102 is configured for control by the manager component 104,and the manager component 104 coordinates the initialization of thedistributed software application 102. Exemplary logic 202 serves toallow the manager component 104 to employ an ordered sequence to shutdown the distributed software application 102. The logic 202 employs oneor more steps, for example, STEPS 204, 206, 208, 210, 212, 214, and 216.An application developer, a system architect, or any other developerperforms the STEP 204 of FIG. 2 and the manager component 104 performsthe STEPS 206, 208, 210, 212, 214 and 216 of FIG. 2.

To shut down the distributed software application 102, the managercomponent 104 shuts down the software components 124, 126, 127 and 128in an ordered sequence based on the dependency relationships among thesoftware components 124, 126, 127 and 128 and/or among the executables106, 107 and 108. Shutting down the distributed software application 102in the ordered sequence serves to save a record of state information,release allocated system resources, and properly update databases. Themanger component 104 serves to shut down the executables 106, 107 and108 according to the ordered sequence. The manager component 104 alsoserves to shut down the software components 124, 126, 127 and 128running within the executables 106, 107 and 108 according to the orderedsequence.

At STEP 204, the application developer or other developer creates theconfiguration file 150 to comprise connection information, architectureinformation, and dependency relationships of the distributed softwareapplication 102. At STEP 206, the manager component 104 imports theconfiguration file 150 to obtain the list of the dependencyrelationships between the software components 124, 126, 127 and 128. AtSTEP 208, the manager component 104 employs the list of dependencyrelationships to establish an ordered sequence for shutdown of thesoftware components 124, 126, 127 and 128 and the executables 106, 107and 108.

At STEP 210, the manager component 104 deactivates the softwarecomponents 124, 126, 127 and 128 according to the ordered sequence. Forexample, the manager component 104 sends deactivation messages to themanagement support software communication interfaces 134 of the softwarecomponents 124, 126, 127 and 128 in the ordered sequence. Thedeactivation messages indicate to the software components 124, 126, 127and 128 to wrap up any current tasks and to not take on any new tasks.The manager component 104 may also instruct the active softwarecomponents of the software components 124, 126, 127 and 128 to not sendnew tasks to the deactivated software components of the softwarecomponents 124, 126, 127 and 128.

In one exemplary implementation of the distributed software application102, the software component 124 has a dependency on the softwarecomponent 126, and the software component 126 (running on the processor110) has a dependency on the software component 128 (running on theprocessor 112). The software component 127 in one example is free fromdependency relationships. Therefore, the manager component 104 may shutdown the software component 127 independently from the other softwarecomponents 124, 126, and 128. To shutdown of the distributed softwareapplication 102 according to the ordered sequence, the manager component104 determines to shut down the software component 124 before thesoftware component 126, and to shut down the software component 126before the software component 128.

To begin shutdown of the software components 124, 126, 127 and 128, themanager component 104 in one example sends a first deactivation messageto the software component 124 and a second deactivation message to thesoftware component 127. Upon deactivation of the software components 124and 127, each the software components 124 and 127 send a confirmationmessage to the manager component 104. Before proceeding, the managercomponent 104 waits for the confirmation message from the softwarecomponent 124 to confirm deactivation of the software component 124.Upon receipt of the confirmation message from the software component124, the manager component 104 may send a third deactivation message tothe software component 126. Before proceeding, the manager component 104waits for a confirmation message from the software component 126 toconfirm deactivation of the software component 126. Upon receipt of theconfirmation message from the software component 126, the managercomponent 104 may send a fourth deactivation message to the softwarecomponent 128. Upon deactivation of the software component 128, thesoftware component 128 sends a confirmation message to the managercomponent 104.

The manager component 104 sends the deactivation messages to themanagement support software 132 of the software components 124, 126, 127and 128. The management support software 132 relays the instruction todeactivate through the application programming interface 136 to theapplication software 130. After deactivation the application software130 sends the confirmation messages to the management support software132. The management support software 132 relays the confirmationmessages to the manager component 104.

Communication between the manager component 104 and the managementsupport software 132 of the software components 124, 126, 127 and 128 isresilient to failure. For example, the messages may employ timeouts tohandle dropped or delayed messages or confirmation notifications. Uponfailure of a deactivation message, the manager component 104 in oneexample employs a configurable number of retries for the deactivationmessage.

Once the manager component 104 has deactivated each of the softwarecomponents 124, 126, 127 and 128 according to the ordered sequence, themanager component 104 may tear down any communication channels betweenthe software components 124, 126, 127 and 128. The manager component 104then may terminate each of the software components 124, 126, 127 and128. At STEP 212, before terminating the software components 124, 126,127 and 128, the manager component 104 instructs the executable managers114 and 116 to stop monitoring the executables 106, 107 and 108. Forexample, the manager component 104 sends a message to the communicationinterface 118 of the executable manager 114 to instruct the executablemanager 114 to stop monitoring the executables 106 and 107. The managercomponent 104 also sends a message to the communication interface 118 ofthe executable manager 116 to instruct the executable manager 116 tostop monitoring the executable 108.

At STEP 214, the manager component 104 sends termination messages to themanagement support software communication interfaces 134 of the softwarecomponents 124, 126, 127 and 128. The termination messages instruct thesoftware components 124, 126, 127 and 128 to stop running. The managercomponent 104 in one example sends the termination messages in theordered sequence based on the dependency relationships of the softwarecomponents 124, 126, 127 and 128, analogously to the deactivationmessages, as described herein.

At STEP 216, the manager component 104 instructs the executable managers114 and 116 to terminate the executables 106, 107 and 108. For example,the manager component 104 sends a message to the communication interface118 of the executable manager 114 to instruct the executable manager 114to terminate the executables 106 and 107. The manager component 104 alsosends a message to the communication interface 118 of the executablemanager 116 to instruct the executable manager 116 to terminate theexecutable 108. Upon shutdown of the executables 106, 107, and 108, theexecutable managers 114 and 116 each send a confirmation message to themanager component 104 to indicate a successful shutdown of theexecutables 106, 107 and 108. Receipt of the confirmation messages fromeach of the executable managers 114 and 116 indicates to the managercomponent 104 that the distributed software application 102 is fullyshutdown. The executable shutdown messages to the executable managers114 and 116 and the confirmation messages are resilient to failure,analogously to the deactivation messages and deactivation confirmationmessages, as described herein.

In one embodiment, the manager component 104 may determine to not followthe ordered sequence to shut down the distributed software application102. If a large number of the software components 124, 126, 127 and 128don't have state information that needs to be preserved and don't needto complete any operations that are in progress, then the managercomponent 104 may just terminate the software components 124, 126, 127and 128 in a more efficient manner, such as in parallel.

The apparatus 100 in one example comprises a plurality of componentssuch as one or more of electronic components, hardware components,and/or computer software components. A number of such components can becombined or divided in the apparatus 100. An exemplary component of theapparatus 100 employs and/or comprises a set and/or series of computerinstructions written in or implemented with any of a number ofprogramming languages, as will be appreciated by those skilled in theart. The apparatus 100 in one example comprises any (e.g., horizontal,oblique, or vertical) orientation, with the description and figuresherein illustrating one exemplary orientation of the apparatus 100, forexplanatory purposes.

The apparatus 100 in one example employs one or more computer-readablesignal-bearing media. The computer-readable signal-bearing media storesoftware, firmware and/or assembly language for performing one or moreportions of one or more embodiments of the invention. Examples of acomputer-readable signal-bearing medium for the apparatus 100 comprisethe recordable data storage medium of the manager component 104. Thecomputer-readable signal-bearing medium for the apparatus 100 in oneexample comprise one or more of a magnetic, electrical, optical,biological, and atomic data storage medium. For example, thecomputer-readable signal-bearing medium comprises floppy disks, magnetictapes, CD-ROMs, DVD-ROMs, hard disk drives, and electronic memory. Inanother example, the computer-readable signal-bearing medium comprises amodulated carrier signal transmitted over a network comprising orcoupled with the apparatus 100, for instance, one or more of a telephonenetwork, a local area network (“LAN”), a wide area network (“WAN”), theInternet, and a wireless network. The steps or operations describedherein are just exemplary. There may be many variations to these stepsor operations without departing from the spirit of the invention. Forinstance, the steps may be performed in a differing order, or steps maybe added, deleted, or modified.

Although exemplary implementations of the invention have been depictedand described in detail herein, it will be apparent to those skilled inthe relevant art that various modifications, additions, substitutions,and the like can be made without departing from the considered to bewithin the scope of the

1. An apparatus, comprising: a manager component in communication with adistributed software application; wherein the distributed softwareapplication comprises a plurality of software components that run withinone or more executables; wherein the manager component shuts down theplurality of software components in an ordered sequence based on one ormore dependency relationships among the plurality of softwarecomponents.
 2. The apparatus of claim 1, wherein the manager componentcomprises a high availability manager component operating in a highavailability infrastructure, wherein the high availability managercomponent shuts down the plurality of software components and the one ormore executables in the ordered sequence.
 3. The apparatus of claim 1,wherein the one or more executables comprise an executable, wherein theplurality of software components comprises a first software componentand a second software component; wherein the first and second softwarecomponents run within the executable; wherein the one or more dependencyrelationships comprise a dependency relationship of the first softwarecomponent on the second software component; wherein based on thedependency relationship on the second software component, the managercomponent shuts down the first software component before shutting downthe second software component as part of the ordered sequence.
 4. Theapparatus of claim 3, wherein the plurality of software componentscomprises a third software component and a fourth software component;wherein the third and fourth software components run within theexecutable; wherein the third and fourth software components are freefrom the one or more dependency relationships; wherein the managercomponent shuts down the third and fourth software components inparallel as part of the ordered sequence.
 5. The apparatus of claim 3,wherein based on the dependency relationship on the second softwarecomponent, the manager component sends a first message to the firstsoftware component to instruct the first software component todeactivate before sending a second message to the second softwarecomponent to instruct the second software component to deactivate;wherein after deactivation of the first and second software components,the manager component sends a termination message to each of the firstand second software components to terminate the first and secondsoftware components.
 6. The apparatus of claim 5, wherein the first andsecond software components each comprise application software,management support software, and an application programming interfacebetween the application software and the management support software;wherein the manager component sends the first message to the managementsupport software of the first software component, wherein the managementsupport software of the first software component instructs theapplication software of the first software component to deactivate;wherein the manager component sends the second message to the managementsupport software of the second software component, wherein themanagement support software of the second software component instructsthe application software of the second software component to deactivate.7. The apparatus of claim 3, wherein the executable runs on a processor,wherein the processor comprises an executable manager that controls theexecutable; wherein the manager component instructs the executablemanager to stop monitoring the executable; wherein after shutdown of thefirst and second software components within the executable, the managercomponent instructs the executable manager to terminate the executable.8. The apparatus of claim 1, wherein the one or more executablescomprise a first executable and a second executable, wherein theplurality of software components comprises a first software componentand a second software component; wherein the first software componentruns within the first executable, wherein the second software componentruns within the second executable; wherein the one or more dependencyrelationships comprise a dependency relationship of the first softwarecomponent on the second software component; wherein based on thedependency relationship on the second software component, the managercomponent deactivates the first software component within the firstexecutable before deactivating the second software component within thesecond executable.
 9. The apparatus of claim 8, wherein the managercomponent deactivates the plurality of software components in theordered sequence across a plurality of processors; wherein the firstexecutable runs on a first processor of the plurality of processors,wherein the second executable runs on a second processor of theplurality of processors; wherein based on the dependency relationship onthe second software component, the manager component deactivates thefirst software component on the first processor before deactivating thesecond software component on the second processor.
 10. The apparatus ofclaim 1, wherein the plurality of software components comprises a firstsoftware component and a second software component within the one ormore executables; wherein the one or more dependency relationshipscomprise a dependency relationship of the first software component onthe second software component; wherein upon startup of the distributedsoftware application, the manager component starts up the secondsoftware component before starting up the first software component;wherein upon shutdown of the distributed software application, themanager component deactivates the first software component beforedeactivating the second software component.
 11. The apparatus of claim1, wherein the manager component obtains the one or more dependencyrelationships from a configuration file; wherein the manager componentimports the configuration file to determine which one or more softwarecomponents of the plurality of software components are effected by theone or more dependency relationships.
 12. The apparatus of claim 1,wherein the manager component employs the one or more dependencyrelationships to establish the ordered sequence for the plurality ofsoftware components; wherein upon shutdown of the distributed softwareapplication, the manager component shuts down the plurality of softwarecomponents according to the ordered sequence to save state information,release system resources, and/or leave the system resources in aconsistent state.
 13. The apparatus of claim 1, wherein the one or moreexecutables comprise a first executable and a second executable; whereinthe plurality of software components run within the first and secondexecutables, wherein the manager component runs within a thirdexecutable; wherein based on one or more characteristics of the firstand second executables, the manager component shuts down the firstexecutable before shutting down the second executable.
 14. The apparatusof claim 1, wherein the distributed software application comprises acall processing software application; wherein the manager componentoversees shutdown of the plurality of software components for the callprocessing software application.
 15. An apparatus, comprising: a managercomponent that shuts down a first software component, of a distributedsoftware application, that runs on a first processor and a secondsoftware component, of the distributed software application, that runson a second processor in an ordered sequence based on one or moredependency relationships between the first and second softwarecomponents.
 16. The apparatus of claim 15, wherein the manager componentcomprises a high availability manager component operating in a highavailability infrastructure, wherein the high availability managercomponent shuts down the first and second software components in theordered sequence.
 17. The apparatus of claim 15, wherein the first andsecond software components each comprise application software,management support software, and an application programming interfacebetween the application software and the management support software;wherein the manager component sends a first deactivation message to themanagement support software of the first software component to instructthe application software of the first software component to deactivate;wherein after deactivation of the first software component on the firstprocessor, the manager component sends a second deactivation message tothe management support software of the second software component on thesecond processor to instruct the application software of the secondsoftware component to deactivate; wherein after deactivation of thefirst and second software components, the manager component sends atermination message to the management support software of each of thefirst and second software components to terminate the first and secondsoftware components.
 18. The apparatus of claim 15, wherein the managercomponent obtains the one or more dependency relationships from aconfiguration file; wherein the manager component employs the one ormore dependency relationships to establish the ordered sequence for thefirst and second software components; wherein during shutdown of thedistributed software application, the manager component shuts down thefirst and second software components in the ordered sequence.
 19. Amethod, comprising the steps of: obtaining one or more dependencyrelationships among a plurality of software components that run withinone or more executables of a distributed software application;establishing an ordered sequence for shutdown of the plurality ofsoftware components based on one or more of the one or more dependencyrelationships; and shutting down the plurality of software componentsaccording to the ordered sequence.
 20. The method of claim 19, whereinthe plurality of software components comprise a first software componentand a second software component; wherein the step of obtaining the oneor more dependency relationships among the plurality of softwarecomponents that run within the one or more executables of thedistributed software application comprises the step of: importing aconfiguration file that indicates a dependency relationship, of the oneor more dependency relationships, of the first software component on thesecond software component; wherein the step of establishing the orderedsequence for shutdown of the plurality of software components based onthe one or more of the one or more dependency relationships comprisesthe step of: determining to shut down the first software componentbefore the second software component based on the dependencyrelationship of the first software component on the second softwarecomponent; wherein the step of shutting down the plurality of softwarecomponents according to the ordered sequence comprises the steps of:sending a first deactivation message to the first software component toinstruct the first software component to deactivate; sending, afterdeactivation of the first software component, a second deactivationmessage to the second software component to instruct the second softwarecomponent to deactivate; and sending, after deactivation of the firstand second software components, a termination message to the managementsupport software of each of the first and second software components toterminate the first and second software components.